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Abstract 

In  this  paper,  we  explain  how  to  achieve  deterministic  execution  of  FMUs  (Functional  Mockup  Units) 
under  the  FMI  (Functional  Mockup  Interface)  standard.  In  particular,  we  focus  on  co-simulation,  where 
an  FMU  either  contains  its  own  internal  simulation  algorithm  or  serves  as  a  gateway  to  a  simulation  tool. 
We  give  conditions  on  the  design  of  FMUs  and  master  algorithms  (which  orchestrate  the  execution  of 
FMUs)  to  achieve  deterministic  co-simulation.  We  show  that  with  the  current  version  of  the  standard, 
these  conditions  demand  capabilities  from  FMUs  that  are  optional  in  the  standard  and  rarely  provided 
by  an  FMU  in  practice.  When  FMUs  lacking  these  required  capabilities  are  used  to  compose  a  model, 
many  basic  modeling  capabilities  become  unachievable,  including  simple  discrete-event  simulation  and 
variable-step-size  numerical  integration  algorithms.  We  propose  a  small  extension  to  the  standard  and 
a  policy  for  designing  FMUs  that  enables  deterministic  execution  for  a  much  broader  class  of  models. 
The  extension  enables  a  master  algorithm  to  query  an  FMU  for  the  time  of  events  that  are  expected  in 
the  future.  We  show  that  a  model  can  be  executed  deterministically  if  all  FMUs  in  the  model  are  either 
memoryless  or  implement  one  of  rollback  or  step-size  prediction.  We  show  further  that  such  a  model  can 
contain  at  most  one  “legacy”  FMU  that  is  not  memoryless  and  provides  neither  rollback  nor  step-size 
prediction. 


1  Introduction 

FMI  (Functional  Mockup  Interface)  is  an  evolving  standard  for  composing  model  components  designed  using 
distinct  modeling  tools  [3,  4,  16,  17,  18].  Initially  developed  within  the  MODELISAR  project,  and  currently 
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supported  by  a  number  of  industrial  partners  and  tools  (see  https :  //www.  f mi- standard .  org/),  FMI  shows 
enormous  promise  for  enabling  the  exchange  and  interoperation  of  model  components.  FMI  is  particularly 
suitable  for  cyber-physical  systems  (CPSs),  where  model  components  may  represent  distinct  subsystems  that 
are  best  designed  with  distinct  modeling  tools.  The  FMI  standard  supports  both  co-simulation  (where  a 
component,  called  an  FMU  (Functional  Mock-up  Unit),  implements  its  own  simulation  algorithm)  and  model 
exchange  (where  an  FMU  describes  the  model  sufficiently  for  an  external  simulation  algorithm  to  execute 
simulation).  In  this  paper  we  focus  the  discussion  on  co-simulation  in  the  current  version  of  the  standard 
(version  2.0,  Beta  4  [16]). 


Figure  1:  A  model  consisting  of  FMUs  connected  in  a  block  diagram. 

A  model  is  a  collection  of  interconnected  FMUs,  as  shown  in  Figure  1.  These  FMU  slaves  are  to  be 
executed  by  some  master  algorithm  (MA),  which  orchestrates  the  execution  of  the  FMUs,  according  to  its 
own  semantics.  The  MA  orchestrates  the  communication  of  the  FMUs  through  their  inputs  and  outputs, 
shown  in  the  figure  as  black  triangles.  The  MA  may  be  the  execution  engine  of  an  established  simulation 
tool  such  as  Simulink,  in  which  case  the  model  may  also  include  native  Simulink  blocks  interacting  with 
the  FMUs.  The  semantics  implemented  by  the  MA  is  that  of  the  host  tool.  Each  FMU  may  have  been 
exported  by  some  other  tool,  such  as  Dymola.  The  goal  of  FMI  is  to  enable  an  FMU  exported  by  one  tool 
to  interoperate  with  a  variety  of  host  tools,  and  for  host  tools  to  orchestrate  interactions  between  FMUs 
exported  by  a  variety  of  other  tools. 

In  principle,  FMI  is  capable  of  composing  components  representing  timed  behavior,  including  physical 
dynamics  and  discrete  events.  However,  there  are  significant  subtleties  and  limitations.  In  particular,  it  is 
possible  to  design  FMUs  and  MAs  that  are  compliant  with  the  standard,  and  yet  exhibit  nondeterministic  and 
unexpected  behavior.  In  this  paper,  we  explain  how  to  achieve  deterministic  execution  of  FMUs.  Specifically, 
the  contributions  of  this  paper  are  the  following: 

•  We  give  conditions  on  the  design  of  FMUs  and  MAs.  With  the  current  version  of  the  standard,  these 
conditions  demand  capabilities  from  FMUs  that  are  optional  in  the  standard  and  rarely  provided  by  an 
FMU  in  practice  (Section  3). 

•  We  clarify  and  formalize  a  subset  of  the  FMI  standard  and  give  constraints  ( contracts )  on  the  expected 
behavior  of  FMUs  and  MAs,  so  that  interoperation  has  consistent  and  predictable  results  (Sections  4). 

•  We  propose  a  master  algorithm  for  the  co-simulation  step  that  only  requires  capabilities  of  the  current 
standard.  We  prove  that  the  algorithm  is  convergent,  determinate,  and  ensures  maximal  progress  (Sec¬ 
tion  5.1). 

•  We  propose  a  small  extension  to  the  standard  that  enables  deterministic  execution  for  a  much  broader 
class  of  models  than  possible  with  the  current  standard.  Specifically,  we  present  a  new  MA  where  all 
FMUs  either  implement  rollback  (which  is  expected  to  be  rarely  supported  by  FMUs)  or  implement  our 
proposed  extension  to  the  standard  (which  is  easier  to  support).  We  show  further  that  such  a  model  can 
contain  at  most  one  FMU  (which  we  call  a  “legacy  FMU”)  that  provides  neither  capability.  We  prove 
that  this  new  algorithm  is  convergent,  determinate,  and  ensures  maximal  progress  (Section  5.2). 
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2  FMI  for  Co-Simulation 

In  this  section,  we  explain  capabilities  and  limitations  of  the  FMI  1.0  and  2.0  beta  4  standards. 

2.1  FMI  1.0 

The  method  provided  by  FMI  for  advancing  time  in  co-simulation  is  called  fmiDoStep.  It  is  implemented 
as  a  C  procedure  by  the  slave  FMU.  The  fmiDoStep  method  is  called  by  the  MA,  which  coordinates  data 
exchange  between  the  slaves  to  control  the  entire  co-simulation.  In  FMI  1.0,  fmiDoStep  has  the  following 
signature  [17]: 

fmiStatus  fmiDoStep ( 
f miComponent  c , 

fmiReal  currentCommunicationPoint , 
fmiReal  communicationStepSize , 
fmiBoolean  newStep) ; 

The  currentCommunicationPoint  argument  is  the  current  simulation  time  of  the  master,  whereas 
communicationStepSize  is  the  time  step  that  the  master  proposes  to  the  slave.  If,  for  example,  the  slave 
encompasses  a  model  with  an  ordinary  differential  equation  (ODE),  then  its  numerical  integration  algorithm 
should  attempt  to  advance  time  by  this  proposed  step.  The  slave  may  accept  or  reject  the  step.  For  instance, 
it  may  reject  it  if  the  step  size  is  too  large  and  hence  causes  a  discrete  event,  such  as  a  zero  crossing,  within 
the  step. 

The  MA  generally  interacts  with  more  than  one  slave,  and  uses  the  boolean  flag  newStep  to  indicate 
whether  the  proposed  step  is  a  new  step,  or  whether  the  previously  attempted  step  was  rejected  by  some 
slave,  and  therefore  is  being  repeated. 

Although  our  paper  is  restricted  to  co-simulation,  we  point  out  an  important  class  of  problems  in  which 
a  MA  not  only  controls  FMUs  for  co-simulation,  but  also  integrates  in  time  FMUs  for  model  exchange  or 
ODEs  that  are  implemented  in  the  simulation  environment  that  provides  the  MA.  In  this  situation,  the  MA 
needs  to  provide  a  time  integration  algorithm.  For  reasons  of  computational  efficiency,  one  may  want  to  use 
an  adaptive  step-size,  multi-step  time  integration  algorithm.  Unfortunately,  FMI  1.0  does  not  support  this, 
as  we  will  now  show.  Consider  a  MA  that  contains  an  adaptive  (variable)  step-size  Runge-Kutta  2-3  solver. 
Let  the  communication  point  be  0  and  the  Runge-Kutta  step  size  be  1.0.  Then,  the  MA  needs  to  obtain 
outputs  from  the  FMU  at  times  0,  0.5,  0.75,  and  1.  Thus,  there  need  to  be  three  calls  to  fmiDoStep,  e.g., 

fmiDoStep (component,  0.0,  0.5,  true); 

fmiDoStep (component,  0.5,  0.25,  ?) ; 

fmiDoStep (component,  0.75,  0.25,  ?) ; 

The  newStep  argument  is  true  in  the  first  call,  but  what  should  it  be  in  the  next  two  calls?  They  cannot 
specify  newStep  =  false,  because  then  the  slave  would  interpret  this  as  restarting  the  previous  computation, 
which  has  an  earlier  communication  point.  But  they  cannot  specify  newStep  =  true  either,  because  if  the 
last  fmiDoStep  is  rejected  by  a  slave,  then  all  three  steps  have  to  be  redone.  “Rolling  back”  more  than  just 
to  the  previous  time  point  ( multistep  rollback )  is  not  possible,  however,  with  the  API  of  FMI  1.0. 

2.2  Extensions  in  FMI  2.0 

The  FMI  2.0  beta  4  [16]  standard  adds  more  methods  to  the  API.  We  will  focus  on  two  important  additions, 
fmiGetFMUstate  and  fmiSetFMUstate,  which  allow  the  master  to  copy  and  later  restore  the  complete  state 
of  an  FMU  slave.  These  procedures  provide  a  general  mechanism  for  rollback,  but  they  are  optional  for 
practical  reasons.  In  practice,  an  FMU  may  wrap  a  large  piece  of  legacy  software,  enabling  the  use  of  that 
software  with  other  modeling  and  simulation  tools,  and  it  may  not  be  practical  to  retrieve  and  restore  the 
state  of  such  a  legacy  system.  We  will  show,  however,  that  if  these  procedures  are  not  provided  by  an  FMU, 
then  that  FMU  will  not  be  usable  in  some  models,  as  the  results  of  executing  the  FMU  will  not  match  the 
intended  semantics  of  the  FMU.  We  give  precise  conditions  under  which  correct  and  deterministic  execution 
of  such  FMUs  is  possible.  In  FMI  2.0  beta  4,  doStep  has  a  slightly  modified  signature  [16]: 
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fmiStatus  fmiDoStep( 
f miComponent  c , 

fmiReal  currentCommunicationPoint , 

fmiReal  communicationStepSize , 

fmiBoolean  noSetFMUStatePriorToCurrentPoint) ; 


The  types  of  the  arguments  are  the  same  as  in  version  1.0,  but  the  name  and  semantics  of  the  boolean 
argument  are  now  different:  by  setting  noSetFMUStatePriorToCurrentPoint  to  true,  the  master  “promises” 
that  it  will  not  call  fmiSetFMUState  for  time  instants  prior  to  currentCommunicationPoint. 

Even  though  the  API  of  FMI  2.0  is  richer,  and  being  able  to  read  and  write  the  state  of  an  FMU  provides 
the  master  with  considerable  power,  the  situation  is  still  not  entirely  satisfactory,  for  a  number  of  reasons. 
First,  implementation  of  the  rollback  procedures  by  an  FMU  is  optional  and  may  be  difficult  to  achieve 
in  practice.  Second,  saving  and  restoring  the  state  may  incur  a  large  overhead  at  run  time.  The  API  is 
not  rich  enough  in  general,  as  we  will  show,  to  prevent  preventable  rollbacks.  Third,  the  interface  does 
not  quite  bridge  the  gap  between  purely  continuous-time  models,  and  other  modeling  formalisms,  such  as 
discrete-event,  synchronous-reactive,  dataflow,  and  state-machines. 

2.3  Extrapolation  of  Input  Values 

For  co-simulation,  time  advances  from  a  communication  point  f  to  a  communication  point  t  +  h  when  the 
MA  calls  fmiDoStep  with  step  size  h.  When  this  call  occurs,  the  FMU  has  been  provided  with  input  values 
at  time  t.  But  many  integration  algorithms  require  input  values  during  the  interval  [t,t  +  h\.  For  example, 
if  an  implicit  solver  is  used,  then  the  input  value  at  t  +  h  will  also  be  needed  in  order  to  determine  the  value 
of  the  state  and  output  at  time  t  +  h.  To  support  this,  the  FMI  standard  allows  for  the  MA  to  provide 
derivatives  of  the  inputs  at  time  t.  The  FMU  will  presumably  then  use  these  derivatives  to  extrapolate  the 
input  signals  to  calculate  suitable  approximations  during  the  interval. 


3  Requirements  of  FMUs 

In  this  section  we  identify  properties  of  FMUs  that  are  required  for  those  FMUs  to  be  executed  determinis¬ 
tically  by  a  MA  in  an  arbitrary  model.  Specifically,  we  illustrate  the  need  for  I/O  dependency  information 
and  the  need  for  rollback.  Currently,  both  of  these  are  optional  in  the  standard.  An  FMU  may  or  may  not 
provide  them. 

3.1  I/O  Dependency  Information 

A  MA  provides  input  data  to  an  FMU  by  calling  a  procedure  called  fmiSetXXX  provided  by  the  FMU, 
where  “XXX”  is  replaced  by  the  data  type  of  the  input.  For  example,  for  a  real-valued  input,  the  MA  will 
call  fmiSetReal.  An  argument  to  this  procedure  specifies  which  input  is  being  set,  and  another  argument 
provides  the  value.  To  retrieve  an  output  value  from  an  FMU,  the  MA  calls  fmiGetXXX,  providing  as  an 
argument  the  identity  of  the  output  and  a  pointer  to  a  location  into  which  to  store  the  output.  A  key 
question  in  the  design  of  an  MA  becomes,  in  which  order  should  these  procedures  be  called?  The  question 
is  particularly  subtle  in  models  with  feedback.1 

To  answer  this  question,  it  is  helpful  to  know  which  outputs  of  an  FMU  depend  immediately  on  which 
inputs.  FMI  makes  it  possible  (although  not  mandatory)  to  provide  such  information.  In  FMI  1.0  this  is 
done  via  the  DirectDependency  element  in  the  XML-description  of  an  FMU  [3,  17,  18].  In  FMI  2.0  this 
information  can  be  provided  using  the  element  ModelStructure  [4,  16].  In  this  section  we  explain  by  example 
why  such  information  is  often  essential. 

1Figure  10  on  page  82  of  [16]  shows  a  statechart  called  the  “State  Machine  of  Calling  Sequence  from  Master  to  Slave”  which 
specifies  the  calling  sequences  of  the  API  methods  which  must  be  supported  by  an  FMU.  Methods  fmiGetXXX  and  fmiSetXXX 
appear  unordered  in  a  self-loop  of  the  state  machine,  however,  therefore  this  state  machine  does  not  help  in  answering  the 
question  above. 
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Suppose  we  want  to  create  an  FMU  with  the  functionality  shown  in  Figure  2.  The  figure  shows  a 
continuous-time  model  modeling  a  trivial  ODE,  where  the  input  u  is  the  derivative  of  the  output  yl ,  and 
the  output  y2  is  the  input  u  multiplied  by  —5.  The  interesting  feature  of  the  model  is  that  output  y2  has  a 
direct  dependency  on  input  u,  whereas  the  output  yl  does  not.  Specifically,  at  any  time  t  in  a  simulation, 
the  output  y2  depends  on  the  value  of  the  input  at  that  same  time  t,  whereas  the  output  yl  depends  only 
on  previous  inputs.  The  equations  realized  by  this  FMU  are 

dy i  , 

“=dF  ®  =  -5“' 

In  general,  a  MA  may  need  to  know  that  yl  can  be  produced  by  the  FMU  even  before  u  is  known.  Suppose 
for  example,  that  we  want  to  use  the  FMU  of  Figure  2  to  simulate  the  following  system  of  equations, 

u  =  f{yi)  u=-^~  V2=  —5  u. 

at 

This  is  shown  in  the  model  to  the  left  of  Figure  3.  How  should  a  MA  execute  this  model?  One  brute  force 
approach  is  to  assume  that  the  feedback  loop  represents  an  algebraic  loop.  The  MA  could  guess  the  value 
of  u  at  a  time,  call  fmiSetReal  to  set  the  input  u  equal  to  this  guess,  then  call  fmiGetReal  to  retrieve  the 
output  values  for  yl  and  y2.  It  could  then  evaluate  the  function  /  and  update  the  value  for  u.  It  could 
repeat  this  process  until  the  value  for  u  no  longer  changes.  And  in  this  example,  indeed,  the  solution  would 
converge  quickly  because  yl  does  not  directly  depend  on  u. 

In  general,  however,  such  an  iterative  technique  for  solving  algebraic  loops  may  not  converge,  and  when 
it  converges,  the  value  it  converges  to  may  depend  on  the  initial  guess.  Suppose  for  example  that  with  the 
same  FMU  of  Figure  2  we  connect  it  as  shown  to  the  right  of  Figure  3.  In  this  case,  there  is  a  genuine 
algebraic  loop.  Suppose  the  function  /  is  the  identity  function.  Then  in  this  case,  if  the  initial  guess  for  u 
is  zero,  then  the  execution  converges  immediately.  If  the  initial  guess  is  anything  other  than  zero,  then  the 
execution  diverges.  Suppose  instead  that  /  is  given  by 

f(x)  =  (0.2  x)2. 

In  this  case,  the  feedback  loop  asserts  that  u  =  u2,  and  there  are  two  possible  solutions,  u  =  0  and  u  =  1 . 
The  solution  that  a  brute-force  MA  converges  to  will  depend  on  the  initial  guess. 

Since  we  are  interested  in  non-diverging  and  deterministic  composition  of  FMUs,  we  need  to  distinguish 
these  two  cases  and  we  need  to  reject  the  case  with  the  algebraic  loop.  That  model  is  not  deterministic. 
A  MA  that  ensures  determinacy  needs  to  know  that  yl  does  not  directly  depend  on  u,  and  that  y2  does. 
Once  it  knows  this,  it  can  also  execute  the  correct  case  (without  the  algebraic  loop)  more  efficiently,  so  we 
get  an  additional  benefit.  In  particular,  the  direct  dependency  information  can  be  used  by  a  MA  to  call 
the  fmiGetReal  and  fmiSetReal  functions  for  outputs  and  inputs  in  a  well-defined  order.  For  the  leftmost 
model  of  Figure  3,  the  MA  can  execute  the  following  sequence: 


Figure  2:  A  continuous-time  FMU  where  output  yl  does  not  have  a  direct  dependency  on  input  u  and  output 
y2  does. 
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Figure  3:  FMU  of  Figure  2  connected  in  feedback  (left)  and  in  an  algebraic  loop  (right). 


1.  Use  fmiGetReal  to  read  the  current  value  of  yl.  This  value  is  available  without  knowing  the  current 
input  u. 

2.  Evaluate  /  (which  may  itself  be  an  FMU  or  it  may  be  a  native  component),  and  use  fmiSetReal  to 
set  the  current  value  of  u. 

3.  Use  fmiGetReal  to  read  the  current  value  of  y2.  Notice  that  since  the  value  of  y2  depends  directly  on 
the  current  value  of  u,  fmiGetReal  needs  to  perform  a  calculation  in  the  case  of  y2.2  Concretely,  it 
needs  to  return  y2  =  —5m. 

Notice  that  in  the  sequence,  fmiGetReal  and  fmiSetReal  are  called  exactly  once,  the  minimum  possible 
number  of  times  for  any  MA. 

For  the  rightmost  example  of  Figure  3,  if  the  MA  has  direct  dependency  information,  then  it  can  identify 
the  algebraic  loop  and  either  reject  the  model  or  alert  the  user  to  the  potential  nondeterminacy. 

3.1.1  Static  Analysis  for  Dependency  Cycles 

For  the  leftmost  example  of  Figure  3,  we  were  able  to  use  I/O  dependency  information  to  identify  the  order 
in  which  the  fmiSetReal  and  fmiGetReal  procedures  should  be  called  at  a  communication  point.  Moreover, 
in  this  ordering,  as  long  as  there  is  no  algebraic  loop,  these  procedures  are  called  exactly  once,  leading  to 
efficient  execution. 

We  can  generalize  this  idea  to  models  with  arbitrarily  complicated  structure,  constructing  a  topological 
sort  of  the  ports  in  a  model.  Consider  the  model  shown  in  Figure  1.  It  consists  of  four  blocks,  A,  B,  C,  D. 
Suppose  that  the  following  is  known  about  the  I/O  dependencies  of  the  blocks  of  Figure  1: 

b\  -»  &4  b3  — >  &2  c3  -»  c2  di  — >  cl 2 

where  x  — »  y  means  that  output  port  y  depends  directly  on  input  port  x.  In  addition,  assume  that  these  are 
the  only  I/O  dependencies.  This  means,  in  particular,  that  output  &2  of  block  B  does  not  depend  on  input 
bi ,  that  the  output  of  C  does  not  depend  on  its  input  C\ ,  and  so  on. 

In  addition  to  the  input-output  dependencies  induced  by  each  block,  output-input  dependencies  are 
induced  by  the  connections  in  the  diagram.  Together  all  these  dependencies  define  a  directed  graph  whose 
nodes  represent  ports.  Each  edge  x  — >  y  in  the  graph  represents  the  fact  that  y  depends  on  x.  The  port 
dependency  graph  for  this  example  is  shown  in  Figure  4. 

As  can  be  observed,  the  port  dependency  graph  of  Figure  4  is  acyclic.  If  the  port  dependency  graph  of 
a  given  model  does  not  contain  cycles,  then  this  graph  can  be  used  to  derive  a  correct  evaluation  order  of 
all  ports  in  the  model.  From  the  port  dependency  graph  shown  in  that  figure,  and  the  knowledge  about 
which  ports  are  inputs  and  which  are  outputs,  a  sequence  of  calls  to  fmiSetXXX  and  fmiGetXXX  can  be  easily 
constructed.  In  general,  the  dependency  graph  resulting  from  such  analysis  gives  a  partial  order  on  the  calls 
to  fmiGetXXX  and  fmiSetXXX,  although  for  the  example  in  Figure  4  the  order  is  total. 

-With  some  care  to  not  do  so  prematurely,  the  calculation  could  alternatively  be  performed  in  the  call  to  fmiSetReal. 
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Figure  4:  The  port  dependency  graph  generated  from  the  model  of  Figure  1.  The  graph  is  acyclic. 


3.1.2  If  I/O  Dependency  Information  is  Missing 

The  FMI  standard  makes  provision  of  I/O  dependency  information  optional,  presumably  under  the  assump¬ 
tion  that  execution  is  still  possible  without  this  information,  albeit  less  efficiently.  Indeed,  this  is  true  if 
all  fmiSetXXX  and  fmiGetXXX  procedures  are  free  of  side  effects  (they  make  no  changes  to  the  state  of  the 
FMU),  and  that  the  corresponding  mechanisms  for  setting  inputs  and  retrieving  outputs  for  native  simula¬ 
tion  components  are  also  free  of  side  effects.  A  MA  can  just  execute  the  model  in  the  same  manner  that 
it  would  solve  algebraic  loops,  repeatedly  invoking  fmiSetXXX  and  fmiGetXXX  until  it  gets  convergence  or 
gives  up  and  declares  a  failure  to  converge. 

However,  these  are  rather  strong  assumptions.  Even  if  a  designer  of  simulation  components  intends  to 
follow  these  guidelines,  it  is  easy  to  make  mistakes.  Such  mistakes  lead  to  very  subtle  bugs  that  are  difficult  to 
track  down.  They  could  also  result  in  nondeterministic  models,  and  the  nondeterminism  might  go  unnoticed 
because  it  fails  to  manifest  as  variable  behavior  during  testing. 


3.2  The  Need  for  Rollback 

A  main  difference  between  FMI  1.0  and  2.0  is  that  FMI  2.0  includes  functions  to  save  and  restore  the  state  of 
an  FMU.  However,  implementation  of  these  functions  by  an  FMU  is  optional,  not  mandatory  [4,  16].  Saving 
and  restoring  the  state  of  an  FMU  can  be  used  to  implement  a  rollback  mechanism,  which  is  often  needed 
as  we  now  explain. 

Consider  the  example  shown  in  Figure  5.  The  figure  shows  two  FMUs  connected  in  series.  Consider  a  MA 
that  co-simulates  these  two  FMUs.  To  advance  time  in  the  simulation,  the  master  needs  to  call  fmiDoStep 
on  both  FMUs.  The  MA  needs  to  pick  an  order  to  do  so;  it  must  either  call  fmiDoStep  first  on  FMU1 
and  then  FMU2,  or  vice-versa.  In  both  cases,  there  is  the  possibility  that  the  FMU  on  which  fmiDoStep  is 
called  first  accepts  the  proposed  communication  step  size  whereas  the  FMU  on  which  fmiDoStep  is  called 
last  rejects  it.  This  is  problematic  as  it  requires  to  roll  back  the  FMU  which  accepted  the  step. 


FMUl^ 


4FMU2^ 


sink 


Figure  5:  Two  FMUs  connected  in  series. 

To  make  the  scenario  more  concrete,  suppose  that  the  MA  calls  first  fmiDoStep  on  FMU1,  passing  a 
communication  step  size  h.  It  means  that  the  MA  “asks”  whether  the  FMU  can  advance  its  local  time 
(and  correspondingly  also  evolve  its  state)  from  the  current  time  t  to  t  +  h.  If  the  FMU  accepts  the  step, 
the  implied  semantics  is  that  the  state  of  FMU1  has  now  evolved  to  a  state  at  future  time  t  +  h.  If  the 
FMU  rejects  the  step,  the  implied  semantics  is  that  the  state  of  FMU1  is  still  the  one  at  time  t  (it  remains 
unchanged).  A  third  possibility  is  that  the  FMU  manages  to  make  partial  progress  and  advance  to  some 
time  t  +  h!  with  h'  <  h. 
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Suppose  for  the  sake  of  this  example  that  FMU1  accepts  h.  Next,  the  MA  calls  fmiDoStep  on  FMU2, 
with  the  same  communication  step  size,  h.  Suppose  that  FMU2  rejects  the  step.  We  are  now  at  a  situation 
where  the  state  of  FMU1  is  at  time  t  +  h,  while  the  state  of  FMU2  is  at  time  t.  To  proceed  with  the 
simulation,  the  master  needs  to  choose  a  new  (smaller)  communication  step  size,  reset  the  state  of  FMU1 
back  to  time  t,  and  repeat  with  the  new  step  size. 

If  FMU2  makes  partial  progress  to  time  t  +  h1,  then  time  has  advanced  to  t  +  h  for  FMU1  and  to  t  +  h' 
for  FMU2.  If  the  MA  chooses  t  +  h'  as  the  next  communication  point,  and  then  calls  fmiGetXXX  to  retrieve 
the  output  of  FMU1,  FMU1  will  likely  respond  with  the  wrong  output  value,  corresponding  to  a  future  time 
point.  Again,  resetting  the  state  (“rolling  back”)  to  time  t  is  necessary.  Note  that  this  is  true  even  in  models 
without  feedback,  as  the  one  shown  in  Figure  5. 

Rolling  back  to  time  t  can  be  achieved  as  follows.  Before  calling  fmiDoStep,  the  MA  uses  fmiGetFMUstate 
to  copy  the  state3  of  both  FMU1  and  FMU2  at  time  t.  It  then  attempts  to  advance  time  by  h.  If  this  is 
accepted  by  both  FMUs,  the  MA  has  succeeded.  Otherwise,  if  say  FMU2  rejects  the  step,  then  the  MA  can 
call  fmiSetFMUstate  on  FMU2  to  reset  it  back  to  its  (copied)  state  at  time  t.  However,  the  implementation 
of  fmiGetFMUstate  and  fmiSetFMUstate  is  left  optional  in  the  FMI  standard. 

Moreover,  it  may  appear  that  if  any  FMU  in  a  model  can  reject  a  step  size,  then  all  FMUs  in  the  model 
need  to  support  rollback.  Indeed,  a  first  algorithm  that  we  present  in  Section  5  (Algorithm  2),  operates  like 
this.  We  will  also  show,  however,  that  with  careful  design  and  with  a  small  extension  to  the  standard,  a 
model  can  contain  some  FMUs  that  do  not  support  rollback  (Algorithm  3). 

4  FMI  Formalization 

In  this  section  we  formalize  a  core  subset  of  FMI  and  propose  an  explicit  contract  between  FMUs  and  MAs. 

4.1  Function  Interface 

The  FMI  standard  describes  the  signatures  of  the  C  functions  together  with  informal  descriptions  of  their 
meaning.  In  this  paper,  we  propose  a  formalization  of  FMI,  which  allows  to  prove  properties  of  MAs,  in 
particular  determinacy  and  maximal  progress  (see  Section  5).  Towards  this  goal,  we  formalize  the  core  subset 
of  the  FMI  2.0  specification,  leaving  out  parts  that  are  not  relevant  for  the  discussion. 

The  formalization  is  summarized  in  Figure  6.  It  consists  of  a  set  of  notations  and  the  signatures  of  four 
(mathematical)  functions,  each  of  which  corresponds  directly  to  a  C  procedure  defined  in  the  FMI  standard. 
For  instance,  doStep  corresponds  to  fmiDoStep,  get  corresponds  to  fmiGetXXX,  and  so  on.  For  simplicity, 
we  do  not  include  all  parameters  provided  in  the  C  functions  and  limit  the  signatures  to  only  essential 
parameters.  Before  giving  an  overview  of  the  functions,  let  us  explain  further  the  notation  used  in  Figure  6. 
C  denotes  the  set  of  all  FMU  instances  that  are  coordinated  by  (the  same)  MA.4  One  such  instance  is  an 
element  c  £  C .  Given  an  instance  c,  Sc  denotes  the  set  of  all  possible  states  that  c  may  be  in,  Uc  denotes 
the  set  of  input  port  variables  of  c,  and  Yc  denotes  the  set  of  output  port  variables  of  c.  At  this  point  we 
ignore  typing  issues,  and  assume  a  single  universe  of  values  for  all  variables,  denoted  V. 

The  XML  file  in  an  FMU  can  (optionally)  express  the  dependencies  between  input  and  output  variables 
of  an  FMU.  We  model  the  set  of  all  such  input/output  (I/O)  dependencies  of  a  given  FMU  instance  c  as  a 
binary  relation  Dc  C  Uc  x  Yc.  Therefore,  (u,  y)  €  Dc  means  that  output  y  of  c  is  directly  dependent  on  input 
u  of  c.  Directly  dependent  means  that  at  a  given  instant  in  time,  the  value  of  u  needs  to  be  known  to  enable 
computation  of  y. 

It  is  convenient  at  this  point  to  also  formalize  the  connections  between  FMU  instances  in  a  model.  We 
do  this  using  a  port  mapping  function  P  :  U  — >  Y,  where  U  and  Y  are  the  sets  of  all  input  and  output 
variables  of  all  instances,  respectively.  P  is  a  total  function  that  maps  every  input  variable  to  a  unique 
output  variable.  This  means  that  we  assume  that  the  model  is  closed;  that  is,  every  input  is  connected  to 

3In  fact,  the  copying  is  done  by  the  FMU  itself  which  returns  a  pointer  to  the  new  copy  of  its  state. 

4Note  that  an  FMU  may  be  instantiated  more  than  once  in  a  co-simulation  environment,  meaning  that  different  instances 
of  the  same  FMU  have  separate  internal  state  variables,  but  share  the  implementation  of  the  FMI  functions  and  solver. 


Set  of  FMU  instances  in  a  model 

C 

FMU  instance  identifier 

c£C 

Set  of  state  valuations  for  instance  c 

sc 

Set  of  input  port  variables  for  instance  c 

Uc 

Set  of  output  port  variables  for  instance  c 

Yc 

Set  of  values  that  a  variable  may  take  on 

V 

I/O  dependency  for  instance  c 

Dc  C  Uc  x  Yc 

Set  of  all  input  variables  in  a  model 

u  =  UceCuc 

Set  of  all  output  variables  in  a  model 

Y  =  l)c&CYc 

Set  of  all  I/O  dependencies 

D  =  UceC  Y>c 

Port  mapping 

P:U  -^Y 

Functions: 

initc  :  K>0  — >  Sc 
setc  :  Sc  x  Uc  x  Y  — >•  Sc 
getc  :  Sc  x  Yc  ->•  Y 
doStepc  :  5C  x  R>o  — >  Sc  x  R>o 


Figure  6:  Formalized  model  of  FMI  and  connections  between  FMU  instances. 


some  output.  Note  that  two  or  more  inputs  may  be  connected  to  the  same  output.  However  an  input  is  not 
allowed  to  be  connected  to  more  than  one  output.  This  is  achieved  by  definition,  since  P  is  a  function. 

We  now  explain  the  functions  in  Figure  6.  Function  initc  corresponds  to  fmilnitializeSlave.  It  initial¬ 
izes  FMU  instance  c  with  given  start  time  t,  corresponding  to  the  argument  tStart  of  fmilnitializeSlave.5 
The  function  returns  the  initial  state  of  the  FMU  instance. 

Function  setc  corresponds  to  fmiSetXXX.  Note  that  FMI  has  not  one,  but  several  such  functions,  including 
fmiSetReal,  fmiSetlnteger,  and  so  on.  Since  we  are  ignoring  data  types,  we  formalize  these  using  a  single 
function  that,  for  given  FMU  instance  c,  given  current  state  s  £  Sc,  input  variable  u  £  Uc,  and  value  v  £  V, 
returns  the  new  state  of  c  obtained  by  setting  u  to  v  and  keeping  the  rest  of  the  state  unchanged.  Similarly, 
getc(s,y)  returns  the  value  of  output  variable  y  of  FMU  instance  c  at  state  s.  Function  getc  corresponds 
to  fmiGetXXX. 

Note  that  both  setc  and  getc  are  by  definition  free  of  observable  side-effects.  This  means  that,  since 
setc  and  getc  are  (total)  mathematical  functions,  given  the  same  input  arguments,  they  always  return  the 
same  result.6  This  formalization  does  not  imply  that  an  FMU  cannot  use  mechanisms  such  as  value  caching 
to  improve  efficiency  of  the  implementation.  This  can  still  be  done  in  an  imperative  implementation  in  C, 
provided  these  mechanisms  do  not  alter  the  semantics.  In  particular,  they  must  guarantee  that  the  result  of 
calling,  say,  getc  multiple  times  without  having  called  setc  or  doStepc  in  between,  is  deterministic;  that  is, 
the  same  value  will  always  be  returned. 

Function  doStepc  takes  as  input  the  current  state  s  of  FMU  instance  c,  and  a  non-negative  real  value 
h  £  R>o,  corresponding  to  the  communicationStepSize  argument  of  fmiDoStep.  Expression  doStepc(s,  h) 
returns  a  pair  (s',  h'),  where  s'  models  the  new  state  of  c  at  the  end  of  the  integration  step,  and  h!  models  the 
amount  by  which  c  managed  to  advance  time.  doStepc  must  guarantee  that  0  <  h'  <  h  (more  about  this  in 
Section  4.2  below).  Note  that  we  allow  h  =  0,  as  well  as  h!  =  0,  enabling  FMI  to  support  a  superdense  model 
of  time,  which  is  widely  acknowledged  to  be  essential  for  proper  modeling  of  hybrid  systems  [15,  12,  13,  2]. 
When  h'  =  h,  this  indicates  to  a  MA  that  the  FMU  is  accepting  the  time  step  proposed  by  the  MA.  When 

5  Time  is  expressed  here  as  a  non-negative  real  value  t  £  K>o-  In  FMI  it  is  implemented  as  a  floating-point  number. 

6 Actually,  the  requirement  on  getc  could  be  relaxed  to  allow  modification  of  the  FMU  state  in  such  a  way  that  consecutive 
getc  calls  will  return  the  same  output  values  and  the  final  FMU  state  does  not  depend  on  the  order  of  getc  calls. 
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h'  <  h,  the  FMU  rejects  the  time  step.7  8 

The  formalization  does  not  include  explicit  functions  corresponding  to  fmiGetFMUstate  and 
fmiSetFMUstate,  which  allow  the  MA  to  save  and  restore  the  state  of  an  FMU  instance.  This  is  not  a 
problem,  as  these  functions  can  easily  be  modeled  in  our  formalization.  Saving  a  state  simply  means  saving 
a  particular  element  s  £  Sc  of  a  particular  instance  c.  Restoring  the  state  simply  means  passing  that  saved  s 
to  subsequent  calls  of  getc,  doStepc,  etc.  This  is  precisely  how  the  algorithm  presented  in  Section  5  works. 

4.2  FMU  Contract 

In  this  section  we  make  explicit  the  utilization  constraints  of  the  FMI  interface  presented  in  Section  4.1.  We 
point  out  that  these  constraints  are  not  always  explicit  in  the  FMI  standard.  In  fact,  some  of  these  constraints 
are  probably  not  even  implicitly  assumed  by  the  authors  of  the  standard.  The  reason  we  introduce  these 
constraints  here  is  because  they  are  crucial  in  proving  the  determinacy  properties  of  the  MAs  presented  in 
Section  5. 

We  call  these  utilization  constraints  the  FMU  contract.  They  consist  of  a  set  of  guarantees  that  every 
FMU  instance  must  provide  to  the  caller  of  the  functions  of  that  instance,  plus  a  set  of  assumptions  that 
every  FMU  instance  makes,  that  is,  conditions  that  the  caller  must  respect  when  calling  these  functions. 

Part  of  the  FMU  contract  is  already  given  by  the  signature  of  the  functions  listed  in  Figure  6.  For 
instance,  the  signature  of  doStepr  implies  that  a  caller  is  not  allowed  to  call  doStep c(s,h)  with  h  <  0.  A 
similar  set  of  constraints  includes  sanity  conditions,  such  as  the  fact  that  get c(s,y)  can  only  be  called  when 
y  £  Yc  (i.e. ,  variable  y  is  indeed  an  output  variable  of  c).  We  will  not  elaborate  further  on  these  and  other 
similar  constraints. 

In  addition  to  the  above,  we  will  assume  that  the  following  constraints  are  also  part  of  the  FMU  contract: 
(AO)  If  doStepc(s,  h )  =  (s',  h')  then  0  <h'<h. 

(Al)  If  doStepc(s,  h )  =  (s',  h '),  then  for  any  h"  where  0  <  h"  <  h',  doStepc(s,  h")  =  ( s ",  h")  for  some  s". 

Assumption  (AO)  has  been  already  stated  above  while  describing  the  intuition  of  doStepc  and  is  repeated 
here  for  completeness.  Assumption  (Al)  states  that  if  an  FMU  accepts  a  certain  time  step  h  (i.e.,  returns 
h!  =  h),  or  at  least  makes  partial  progress  until  h'  <  h,  then  it  must  accept  any  time  step  h"  smaller  than 
or  equal  to  h' ,  provided  the  FMU  is  started  from  the  same  original  state. 

The  following  assumptions  formalize  the  expected  behavior  of  get  and  set.  Let  us  first  introduce  some 
notation.  Given  state  s  £  Sc  of  some  instance  c  £  C,  and  given  input  variable  u  £  Uc.  and  value  v  £  V,  we 
denote  by  s'  =  s[it  :=  i>]  the  state  that  is  identical  to  s,  except  that  s'  assigns  value  v  to  variable  u,  whereas 
s  may  assign  to  u  a  different  value. 

(A2)  Let  s'  =  set c(s,u,v).  Then  s'  =  s[u  :=  i>]. 

(A3)  Let  v  =  get c(s,y)  and  v'  =  getc(s',  y).  If  s'  =  s[iti  :=  v\,  ...,Uk  :=  14-],  and  output  variable  y  does  not 
directly  depend  on  any  input  u\,  ...,itfc,  then  v'  =  v. 

The  latter  simply  formalizes  I/O  dependencies. 

"Tins  reject  is  often  caused  by  zero-crossing  or  another  discrete  change  that  the  FMU  detects.  But  zero-crossings  or  other 
overlooked  events  are  sometimes  detected  only  after  an  input  is  provided  by  set,  e.g.,  when  that  input  violates  the  validity 
range  of  the  extrapolated  input  values  in  the  previous  doStep.  This  possibility  can  be  handled  in  FMI  2.0  using  the  fmiDiscard 
callback  which  may  be  returned  by  fmiSetXXX.  In  this  paper  we  assume  doStep  to  be  the  only  place  where  an  FMU  can  reject 
the  proposed  time  step.  We  plan  to  lift  this  assumption  in  the  future. 

8In  this  formalization  we  assume  that  FMUs  can  have  both  zero  and  variable  communication  step  size.  (The  XML  elements 
canHandleVariableCommunicationStepSize  and  canHandleEvents  are  both  enabled.) 
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5  Determinate  Execution 


This  section  presents  two  MAs  that  are  formally  proven  to  have  the  desirable  properties  of  termination  (of 
an  integration  step)  and  determinacy  (different  runs  of  the  algorithm  produce  the  same  result).  First,  we 
present  a  MA  requiring  all  FMUs  to  support  rollback.  This  is  followed  by  a  second  MA  that  relaxes  this 
constraint.  The  latter  algorithm  uses  a  proposed  extension  to  the  FMI  standard,  which  enables  the  MA  to 
query  the  FMU  for  expected  future  time  events. 

5.1  Algorithm  Requiring  Rollback 

We  first  give  a  preprocessing  algorithm  that  creates  a  list  of  variables,  describing  the  order  that  the  variables 
may  be  accessed.  Recall  that  P  denotes  the  mapping  of  input  ports  to  output  ports  and  D  the  global 
input-output  dependency  relation  (see  Figure  6).  Let  X  =  XJ  U  Y,  that  is,  X  is  the  set  of  all  input  and 
output  variables  in  the  model. 


Algorithm  1:  Order- Variables. 

Input:  Port  mapping  P,  global  dependency  relation  D ,  and  global  set  of  variables  X. 

Output:  An  ordered  list  x  of  variables,  or  error. 

1.  Let  G  be  a  directed  graph,  where  the  vertices  are  represented  by  port  variables  X  and  an  edge  e  £  X  x  X 
is  a  variable  dependency.  The  set  of  all  edges  E  is  then  constructed  by  E  =  DU{(j;,  u)  \  u  £  U A P(u)  = 

y}- 

2.  Perform  a  topological  sort  on  G.  If  a  cycle  in  G  is  found,  terminate  and  return  error.  If  no  cycles  are 
found,  the  resulting  list  of  variables  is  x. 


In  the  following  we  assume  that  algorithm  Order-Variables  returns  no  error  (i.e. ,  G  is  acyclic).  In  that  case, 
based  on  the  variable  list  x  returned  by  this  algorithm,  the  MA  executes,  for  each  communication  step,  the 
algorithm  Master-Step  given  below.  We  use  the  following  notation:  given  variable  x  £  X,  cx  denotes  the 
(unique)  FMU  instance  c  £  C  to  which  x  belongs.  That  is,  if  a :  £  U  then  cx  is  the  unique  c  such  that  x  £  Uc, 
and  if  x  £  Y  then  cx  is  the  unique  c  such  that  x  £  Yc.  We  represent  the  states  of  all  FMU  instances  as  a 
mutable  mapping  to,  mapping  a  FMU  instance  identifier  c  £  C  to  a  state  valuation  s  £  S.  Expression  m[c]  is 
the  current  state  valuation  for  FMU  instance  identifier  c.  We  use  statement  m[c]  :=  s  to  denote  that  the  state 
for  c  is  updated  to  be  s.  Note  that  at  each  stage  in  the  execution  of  the  algorithm,  the  state  mapping  may 
formally  be  viewed  as  a  function  m  :  C  S.  Because  the  domain  C  is  a  set,  the  elements  of  to  are  unordered. 


Algorithm  2:  Master-Step. 

Input:  Set  of  instances  C,  ordered  variable  list  x.  port  mapping  P,  the  maximal  step  size  hmaxi  and  a 
mutable  state  mapping  to  of  size  \C\. 

Output:  Updated  state  mapping  to  and  the  performed  step  size  h. 

1.  Set  values  for  all  input  variables: 

For  each  u  £  x  (in  order)  where  u  £  U  do 

(a)  y  :=  P(u) 

(b)  v  :=  get Cy(m{cy\,y) 

(c)  m[cu]  :=  set Cn(m[cu\,u,v) 

2.  Save  the  states  of  all  FMUs  to  enable  rollback: 

r  :=  to 

3.  Set  communication  step  size  to  an  initial  default  value: 

fo  • —  fomax 

4.  Find  h  acceptable  by  all  FMUs: 

For  each  c£  C  do 
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(a)  {s',h')  :=  doStepc(m[c],ftmox) 

(b)  ft  :=  min(h ,  ft /) 

(c)  m[c]  :=  s' 

5.  Assert  0  <  ft  <  hmax  //  follows  from  Assumption  (AO) 

6.  If  ft,  <  ftmax  then  //  roll  back  and  perform  step  ft 

For  each  c  €  C  do 

(a)  (s',  ft')  :=  doStep(r[c],  ft) 

(b)  Assert  ft ’  =  ft,  //  follows  from  Assumption  (Al) 

(c)  m[c]  :=  s' 

7.  Return  m  and  ft. 


Intuitively,  in  Step  4  the  algorithm  “sweeps”  over  all  FMUs,  attempting  to  perform  step  hmax  on  each  of 
them.  At  the  same  time  the  algorithm  records  the  smallest  actually  achieved  step,  ft.  At  the  end  of  Step  4,  if 
ft  =  hmax,  then  hmax  was  accepted  by  all  FMUs,  and  the  step  is  complete.  Otherwise,  by  Assumption  (AO), 
it  must  be  that  ft  <  hmax.  In  that  case  the  algorithm  makes  a  second  pass,  performing  step  ft  on  all  FMUs. 
Thanks  to  Assumption  (Al),  this  is  bound  to  be  accepted  by  all  FMUs. 

Clearly,  both  Algorithms  1  (Order- Variables)  and  2  (Master-Step)  terminate,  as  our  models  (set  of  FMU 
instances,  ports,  connections,  etc.)  are  finite. 

A  useful  notion,  used  in  particular  to  prove  Theorem  1  that  follows,  is  the  notion  of  acceptable  time  step. 
Let  c  €  C,  s  €  Sc  and  ft  €  R>o-  We  say  that  ft  is  acceptable  by  c  at  state  s  if  doStepc(s,  ft)  =  (s',  ft)  for  some 
s'.  If  to  is  a  global  state  mapping,  then  we  say  that  ft  is  acceptable  at  m  if  for  all  c  G  C,  h  is  acceptable  by 
c  at  m[c]. 

Theorem  1  (Determinacy).  Algorithm  2  (Master-Step)  is  determinate  in  the  sense  that,  for  given  inputs 
C ,  P,  hmax,  and  m,  the  returned  updated  output  state  mapping  m  and  ft  are  the  same  no  matter  what  the 
ordered  list  x  produced  by  Algorithm  1  (Order-Variables)  is  and  no  matter  which  order  the  instances  c  G  C 
are  selected  in  Algorithm  2. 

Proof.  Denote  mi  to  be  the  state  mapping  at  start  of  Step  1  and  to  be  the  state  mapping  at  the  start 
of  Step  2.  We  first  show  that  m2  is  uniquely  defined  (Lemma  1). 

Lemma  1.  State  mapping  m2  is  uniquely  defined,  independently  of  what  the  ordered  list  x  produced  by 
algorithm  Order- Variables  is. 

of  Lemma  1.  Let  u\ . . .  un  be  the  sequence  of  topologically  sorted  input  variables  and  nSNbe  the  variable 
index.  We  prove  by  strong  mathematical  induction  over  n  that  m  [cUn ]  in  step  lc  is  uniquely  defined  for  n  >  1. 
(i)  Basic  step:  Input  variable  U\  is  defined  by  output  variable  y  =  P(ui).  Because  the  topological  sort  is 
assumed  to  succeed,  y  must  be  a  start  node  in  graph  G  (step  1  in  Algorithm  1).  Consequently,  get (m[cy\,y) 
can  only  have  one  value  and  therefore  the  value  assigned  for  u±  is  uniquely  defined,  (ii)  Inductive  step: 
Assume  that  values  in  m  for  variables  U\  ...  un  are  uniquely  defined.  We  now  show  why  the  value  for  ura+ 1 
is  uniquely  defined.  Let  y  =  P(un+ 1)  be  the  output  variable  that  holds  the  value  that  variable  un+±  will  be 
assigned  to  in  Step  1(c).  We  will  show  that  the  value  assigned  to  un+ 1  in  Step  1(c)  is  unique.  In  addition, 
from  assumption  (A2),  set  only  affects  the  value  of  the  variable  being  assigned,  therefore,  the  values  of 
previously  assigned  variables  do  not  change.  To  show  that  the  value  assigned  to  un+ 1  is  unique  we  consider 
two  cases.  Case  1:  It  does  not  exist  an  x  such  that  ( x,  y )  €  D,  that  is,  y  is  not  directly  dependent  on  any 
input  variables.  In  this  case,  according  to  assumption  (A3),  get (m[cv\,y)  is  not  affected  by  setting  input 
values  to  instance  cy.  The  value  for  output  variable  y  is  unique  and  consequently  is  the  value  for  un+ 1  unique 
in  Step  1(c).  Case  2:  There  exist  a  set  of  directly  dependent  input  variables  X  =  {x  |  (x,  y)  G  D}.  By  the 
property  of  topological  sort,  we  have  that  every  x  G  X  must  come  before  both  y  and  un+\  in  the  sorted 
sequence  of  variables.  Because  each  x  G  X  corresponds  to  a  Uk  where  k  <  n,  we  have  by  the  induction 
hypothesis  that  the  values  for  x  G  X  are  uniquely  defined.  Since  the  values  for  x  is  set  before  the  value 
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get (m[cy],y)  is  retrieved,  the  value  for  y  in  Step  1(b)  is  unique  and  therefore  also  the  value  for  un+ 1  in 
Step  1(c).  Finally,  we  can  conclude  that  the  state  mapping  m2  is  uniquely  defined  because  all  elements  set 
in  Step  1(c)  are  uniquely  defined.  □ 

Since  r  is  simply  a  copy  of  m2,  Lemma  1  also  proves  that  the  state  mapping  r  computed  at  the  end  of 
Step  2  is  unique,  independently  of  what  the  ordered  list  x  produced  by  algorithm  Order-Variables  is. 

We  next  prove  that  the  h  computed  at  the  end  of  Step  4  is  uniquely  defined,  independently  of  the  order 
in  which  FMU  instances  are  chosen  in  the  loop  iteration  of  Step  4.  Indeed,  it  can  be  easy  to  see  that  this  h 
is  equal  to 

min{h'  |  c  €  C,  (_,  h!)  =  doStepc(m[c],  hmax)}. 

and  therefore  uniquely  defined. 

The  assertion  of  Step  5  holds  since,  by  Assumption  (AO),  doStepc(m[c],  hmax)  always  returns  0  <  h  < 
hmax-  At  this  point,  if  h  =  hmax,  then  the  algorithm  returns  state  mapping  7714  and  hmax,  where  777.4 
is  equal  to  the  current  state  mapping  rn.  Then,  7774  is  uniquely  defined  by  the  equality  (7774 [c],  hmax)  = 
doStepc(?772[c],  hmax),  for  all  c  €  C. 

Otherwise,  h  <  hmax.  In  this  case,  Step  6  is  executed,  which  corresponds  to  rolling  back  to  saved  state 
mapping  r,  and  performing  the  computed  step  h.  By  Assumption  (Al),  h  is  guaranteed  to  be  acceptable  by 
all  FMUs.  Therefore,  the  assertion  of  Step  6(b)  is  satisfied  for  all  c  €  C,  and  at  the  end  of  Step  6  the  algorithm 
returns  state  mapping  m§  and  h,  where  mg  is  uniquely  defined  by  the  equality  (to6[c],  h )  =  doStepc(r[c],  h), 
for  all  c  €  C. 

This  completes  the  proof  of  Theorem  1.  □ 


As  can  be  seen  from  the  proof  of  Theorem  1  ,  Algorithm  2  is  not  only  determinate,  but  is  also  correct 
in  the  following  sense.  If  m2  is  the  state  mapping  after  executing  Step  1,  and  m,h  are  the  values  returned 
by  Algorithm  2,  then  for  all  c  £  C,  doStepc(m2[c],  h)  =  ( m[c],h ).  This  means  that  Algorithm  2  returns  an 
acceptable  time  step  h  and  the  state  mapping  which  would  result  as  if  all  FMUs  performed  this  step  just 
once. 

It  is  also  desirable  to  show  that  a  master  algorithm  achieves  maximal  progress,  i.e.,  it  achieves  the  maximal 
acceptable  step  h.  We  would  thus  like  to  state  the  following. 

Theorem  2  (Maximal  progress).  Let  m2  be  the  state  mapping  after  executing  Step  1  of  Algorithm  2  and  let 
h  be  the  step  returned  by  Algorithm  2.  There  is  no  h'  such  that  h  <  h'  <  hmax  and  h'  is  acceptable  at  777.2. 

We  can  prove  Theorem  2  provided  all  FMUs  satisfy  an  additional  assumption: 

(PI)  If  doStepc(s,  h)  =  (s',  h')  and  h'  <  h,  then  for  all  h"  >  h' ,  doStepc(s,  h")  =  (s",  h')  for  some  s" . 

Assumption  (PI)  says  that  every  FMU  makes  maximal  progress  at  the  individual  level.  Note  that  (PI)  is 
not  implied  by  (Al).  For  instance,  let  doStepc(s,  h)  =  ( s,h ')  where 


h'  = 


h  if  h  <  1 
\  otherwise. 


Then  c  violates  (PI)  whereas  it  satisfies  (Al).  This  example  also  shows  why  (PI)  is  necessary  for  maximal 
progress.  If  (PI)  does  not  hold,  then  we  can  easily  construct  a  counter-example  where  Algorithm  2  does 
not  ensure  maximal  progress.  Consider  a  model  with  a  single  FMU,  c,  and  initial  state  s,  as  above.  Then, 
starting  with  step  size  hmax  =  2,  Algorithm  2  will  make  progress  only  up  to  whereas  progress  up  to  1  can 
also  be  made. 


Proof  of  Theorem  2.  Suppose  the  contrary,  i.e.,  there  is  h!  such  that  h  <  h!  <  hmax  and  h!  is  acceptable  at 
m2.  This  means  that  for  all  c  £  C,  h!  is  acceptable  by  c  at  7772(0],  i.e.,  for  all  c  G  C,  there  exists  s,  such  that 
doStepc(?772[c],  h')  =  ( s,h ').  Now,  since  h  is  returned  by  Algorithm  2,  and  h  <  hmax,  there  must  exist  some 
FMU  c*  and  some  state  s*  of  c*  such  that  doStepc,  (t772[c*],  hmax)  =  ( s *,  h).  It  can  now  be  seen  that  this  c* 
contradicts  Assumption  (PI). 

This  completes  the  proof  of  Theorem  2.  □ 
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We  end  this  section  with  a  remark.  Algorithm  2  may  appear  wasteful  in  the  sense  that  Step  4  continues 
attempting  to  perform  step  hmax  on  the  rest  of  the  FMUs  even  after  it  encounters  an  FMU  which  rejects  hmax. 
An  alternative  would  be  to  call  doStep  in  Step  4(a)  with  h  instead  of  hmax-  In  addition,  the  algorithm  can 
keep  track  of  which  FMUs  have  already  been  executed  with  the  right  h,  so  that  it  does  not  re-run  them.  This 
modification  can  be  shown  to  terminate  (due  to  Assumption  (Al)).  It  can  also  be  shown  to  be  determinate, 
provided  Assumption  (PI)  holds.  Note  that  Assumption  (PI)  is  not  needed  for  Theorem  1. 

5.2  Predictable  Step  Sizes 

The  algorithm  given  above  requires  all  FMUs  to  implement  rollback.  In  many  cases,  this  is  impractical, 
particularly  when  an  FMU  wraps  legacy  code  or  serves  as  a  wrapper  for  a  simulation  tool.  Fortunately,  with 
a  small  addition  to  the  FMI  standard,  such  FMUs  can  be  handled  in  certain  cases.  Specifically,  we  propose 
the  addition  of  a  procedure 

fmiStatus  fmiGetMaxStepSize( 
f miComponent  c , 
fmiReal  *maxStepSize) ; 

where  the  argument  returns  an  upper  bound  on  the  step  size  that  the  FMU  can  accept  (or  infinity  if 
there  is  none).  This  bound  could  be  zero  to  indicate  the  need  for  a  zero-step-size  step.  We  use  the  function 

getMaxStepSizec :  Sc  — >  R>o  U  {oo}  (1) 

to  model  the  fmiGetMaxStepSize  procedure.  Let  Cp  be  the  set  of  FMU  instances  that  implement  this 
function.  We  require  of  these  instances  that 

(A4)  If  c  £  Cp  and  s  £  Sc  and  getMaxStepSizec(s)  =  h  then  for  all  h!  where  0  <  h'  <  h.  doStepc(s,  h!)  = 
(s',h')  for  some  s'. 

This  means  that  an  instance  in  Cp  will  accept  any  time  step  smaller  than  or  equal  to  the  time  step  returned 
by  getMaxStepSize.  Whether  an  FMU  is  in  Cp  should  be  indicated  as  a  capability  in  the  FMU  XML  file. 
Let  Cp,  be  the  set  of  FMU  instances  with  rollback  capability,  i.e.,  every  c  €  Cp  supports  setting  and  getting 
states.  Furthermore,  let  Cl  be  the  set  of  FMU  instances  in  a  model  that  are  not  in  Cp  and  not  in  Cp. 
We  will  call  these  FMUs  “legacy  FMUs”.  Then,  we  can  give  a  MA  that  is  determinate  under  the  following 
assumption. 

(A5)  (a)  \CL\  <  1. 

(b)  CL  U  Cp  U  CP  =  C. 

(c)  CLnCR  =  9  and  CRnCP  =  9  and  CPCCL  =  0. 

That  is,  a  model  that  composes  FMUs  has  at  most  one  legacy  FMU  instance,  and  the  remaining  instances 
all  either  provide  predictable  step  sizes  or  support  rollback.9 


9  If  an  FMU  supports  both  predictable  step  sizes  and  rollback,  our  algorithm  only  uses  its  predictable  step  sizes  capability, 
so  we  put  it  in  set  Cp  and  not  in  Cp. 
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Algorithm  3:  Master-Step  With  Predictable  Step  Sizes. 

Input:  Set  of  instances  C,  ordered  variable  list  x,  port  mapping  P,  the  maximal  step  size  hmax ,  and  a 
mutable  state  mapping  m  of  size  \C\. 

Output:  Updated  state  mapping  m  and  the  performed  step  size  h. 

1.  Set  values  for  all  input  variables: 

For  each  u  £  x  (in  order)  where  u  £  U  do 

(a)  y  :=  P(u) 

(b)  v  :=  get Cy(m[cy],y) 

(c)  m[cu\  :=  setCu  (m[cu\,u,  v) 

2.  Find  the  minimal  predictable  communication  size: 

h  :=  mm({getMaxStepSizec(m[c])  |  c  £  Cp}  U  {hmax}) 

3.  Save  the  states  for  all  instances  that  can  perform  rollback: 

(a)  For  each  c  £  Cp  do  r[c]  :=  m[c] 

(b)  doStepOnLegacy  :=  true 

(c)  Goto  step  5. 

4.  Restore  states  for  rollback  instances. 

For  each  c  £  Cp  do  m[c]  :=  r[c] 

5.  Perform  doStep  on  all  instances  with  rollback: 
hmin  • —  h 

For  each  c  £  Cp  do 

(a)  (s',  h')  :=  doStepc(m[c],  h) 

(b)  hmin  :=  min(h  ,  hm^n) 

(c)  m[c]  :=  s' 

6.  If  hmin  <  h  then  h  :=  hrnln  and  goto  step  4. 

7.  Perform  doStep  on  the  legacy  FMU  (if  it  exists) 

If  c  £  Cl  and  doStepOnLegacy  then 

(a)  (s',  h!)  :=  doStepc  (rn[c],  h) 

(b)  m[c]  :=  s' 

(c)  doStepOnLegacy  :=  false 

(d)  If  h!  <  h  then  h  :=  h'  and  goto  step  4. 

8.  Perform  doStep  on  all  FMUs  with  predictable  step  size: 

For  each  c  £  Cp  do 

(a)  (s',  h!)  :=  doStepc(m[c],  h) 

(b)  Assert  h!  =  h  //  follows  from  Assumption  (A4) 

(c)  m[c]  :=  s' 

9.  Return  m  and  h. 


With  such  a  MA,  a  collection  of  FMUs  can  always  be  executed  deterministically  if  there  is  at  most  one 
“legacy  FMU” .  Note  that  Algorithm  2  can  be  extended  easily  to  also  support  at  most  one  FMU  that  does 
not  implement  rollback. 

Theorem  3  (Termination).  Algorithm  3  (Master-Step  With  Predictable  Step  Sizes)  terminates. 

Proof.  Step  1  terminates  because  a:  is  a  finite  list.  Each  of  the  steps  2,  3,  4,  and  5  terminate  because  Cp  and 
Cp  are  finite  sets.  The  algorithm  contains  two  goto  statements:  one  at  step  6  and  one  at  step  7.  Each  of 
these  goto  statements  can  be  executed  at  most  once,  which  will  show  next.  The  first  time  step  5  is  executed, 
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step  6  may  go  to  step  4  if  not  all  doStep  succeed.  They  will  all,  however,  succeed  the  second  time  step  5  is 
executed  because  of  Assumption  Al.  Note  that  doStep  is  performed  on  all  instances  with  the  same  h  and 
that  the  smallest  step  size  hmin  is  used  the  second  time  step  5  is  executed  (if  any).  If  Cl  =  0  or  h!  =  h  in 
step  7a,  step  7  terminates  and  goes  to  step  8.  If  Cl  is  not  empty  and  h!  <  h,  the  algorithm  goes  to  step 
4.  In  this  case,  step  6  cannot  loop  back  to  step  4,  because  Assumption  Al  assures  that  all  calls  to  doStep 
in  Step  5  succeed  ( h  updated  in  step  7  is  necessarily  smaller  than  the  h  used  in  previous  round  of  step  5). 
Also,  because  doStepOnLegacy  =  false  the  second  time  step  7  is  executed,  it  will  not  loop  back  to  step  4. 
Finally,  step  8  terminates  because  Cp  is  finite. 

This  completes  the  proof  of  Theorem  3.  □ 

Theorem  4  (Determinacy).  Algorithm  3  (Master-Step  With  Predictable  Step  Sizes)  is  determinate  in  the 
sense  that,  for  given  inputs  C,  P,  hmax,  and  m,  the  updated  output  state  mapping  m  and  the  output  step 
size  h  are  the  same  no  matter  what  the  ordered  list  x  produced  by  Algorithm  1  (Order-Variables)  is  and  no 
matter  the  order  of  how  c  £  C  are  selected  in  Algorithm  3. 

Proof.  Step  1  of  Algorithm  3  is  identical  to  step  1  in  Algorithm  2;  determinacy  for  step  1  is  therefore  proven 
analogously  to  the  proof  of  Algorithm  2  using  Lemma  1.  The  step  size  h  in  step  2  and  the  store  mapping 
r  in  step  3  are  clearly  uniquely  defined.  Variable  h  is  only  updated  in  step  6  and  7b,  and  only  one  time  in 
each  step.  Consequently,  h  does  not  depend  on  the  order  how  c  £  C  is  selected  an  therefore  uniquely  defined 
at  the  end  of  the  algorithm. 

We  now  consider  how  subsets  of  the  mapping  of  m  are  uniquely  updated.  By  Assumption  A5  we  see  that 
the  subsets  Cp ,  Cp,  and  Cp  are  distinct.  We  can  also  observe  that  in  each  of  the  steps  4,  5,  7,  and  8,  only 
a  distinct  subset  of  m  is  updated,  and  in  each  step  each  element  is  updated  only  once.  Finally,  compared 
to  m.2  (end  of  step  2),  each  element  is  updated  at  most  once.  For  instances  c  £  Cp,  m  can  be  updated 
in  step  5,  but  this  step  is  always  preceded  by  either  the  original  m2  state  mapping  or  a  rollback  of  states 
(step  4)  to  the  states  in  m2.  An  instance  c  £  Cl,  is  only  updated  once  because  of  the  guarding  boolean 
variable  doStepOnLegacy .  Finally,  for  instances  c  £  Cp,  updates  in  m  is  only  performed  once  in  step  8.  By 
Assumption  A4,  we  see  that  the  assertion  at  8b  holds. 

Consequently,  we  conclude  that  at  the  end  of  Step  9  the  algorithm  returns  state  mapping  mg  and  hg, 
where  mg  is  uniquely  defined  by  the  equality  doStepc(?77.2[c],  hg)  =  (mg[c],  hg),  for  all  c  £  C. 

This  completes  the  proof  of  Theorem  4.  □ 

Analogously  to  the  discussion  of  correctness  for  Algorithm  2,  we  can  see  in  Theorem  4  that  Algorithm  3  is  not 
only  determinate,  but  is  also  correct  in  the  following  sense:  if  m2  is  the  state  mapping  after  executing  Step  2, 
and  mg,  hg  are  the  values  returned  by  Algorithm  3,  then  for  all  c  £  C,  doStepc(m.2[c],  hg)  =  (mg[c],  hg). 

We  next  prove  maximal  progress  for  Algorithm  3.  Again  we  assume  (PI)  on  all  FMUs.  In  addition,  we 
need  the  following  assumption  for  FMUs  with  predictable  step  sizes: 

(P2)  If  c  £  Cp  and  s  £  Sc  and  getMaxStepSizec(s)  =  h  then  for  all  h!  >  h,  doStepc(s,  h')  =  ( s' ,h )  for 
some  s' . 

Theorem  5.  Let  m 2  be  the  state  mapping  after  executing  Step  1  of  Algorithm  3  and  let  h  be  the  step  returned 
by  Algorithm  3.  There  is  no  h!  such  that  h  <  h'  <  hmax  and  h!  is  acceptable  at  m.g- 

Proof.  Suppose  the  contrary,  i.e. ,  there  is  h!  such  that  h  <  h'  <  hmax  and  h'  is  acceptable  at  m2.  This 
means  that  for  all  c  £  C,  h'  is  acceptable  by  c  at  ?ri2[c],  i.e.,  for  all  c  £  C,  there  exists  s,  such  that 
doStepc(?7i2[c],  h')  =  ( s,h' ). 

Let  hp  be  the  h  computed  at  Step  2  of  Algorithm  3,  i.e., 

hp  =  mm({getMaxStepSizec(m[c])  |  c  £  Cp}  U  {hmax})- 

We  claim  that  h!  <  hp.  Otherwise,  there  is  some  c  £  Cp  such  that  doStepc(?n2[c],  h')  =  ( s,h '),  yet 
getMaxStepSizec(m[c])  <  h! ,  which  violates  Assumption  (P2). 
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Now,  since  h  is  returned  by  Algorithm  3,  there  must  exist  some  FMU  c*  £  C,  some  state  s*  of  c*,  aud 
some  h* ,  such  that  h  <  h*  <  hp,  and  doStepc,  (m2[c*],  h*)  =  ( s*,h ).  It  can  now  be  seen  that  this  c* 
contradicts  Assumption  (PI). 

This  completes  the  proof  of  Theorem  5.  □ 


6  Related  Work 

This  paper  focuses  on  co-simulation  rather  than  model  exchange  because  it  more  loosely  couples  simulation 
tools.  Co-simulation  enables  the  principle  of  hierarchical  heterogeneity ,  pioneered  in  the  Ptolemy  Project  [9], 
where  multiple  models  of  computation  (MoCs)  are  combined  hierarchically.  Since  an  FMU  for  co-simulation 
includes  its  own  simulation  engine,  there  is  no  requirement  that  its  simulation  engine  match  precisely  the 
semantics  of  the  host  simulator.  It  only  has  to  be  capable  of  providing  the  semantics  of  the  FMI  interface 
(a  semantics  that  this  paper  clarifies).  In  model  exchange,  the  host  simulator  semantics  prevail,  and  any 
differences  in  semantics  intended  by  the  author  of  the  FMU  will  be  subjugated.  In  effect,  this  means  that 
the  author  of  the  FMU  and  the  author  of  the  host  simulator  have  to  agree  on  the  semantics.  Such  agreement 
has  been  shown  to  rarely  exist  even  within  communities  working  on  closely  related  modeling  techniques, 
as  evidenced,  for  example,  by  the  failure  of  the  Hybrid  Systems  Interchange  Format,  HSIF  [22,  23,  26]. 
Such  agreement  has  also  proven  impossible  to  achieve  in  communities  with  broader  interests,  such  as  the 
UML  community,  where  a  plethora  of  semantic  variants  exist  for  nearly  every  UML  notation.  Co-simulation 
enables  interoperation  even  in  the  absence  of  agreement  about  semantics. 

Despite  these  benefits,  state-of-the-art  co-simulation  is  still  quite  limited.  To  quote  from  the  FMI  stan¬ 
dard  [17]: 

“In  contrast  to  classical  (mono-disciplinary)  simulation  techniques  in  system  dynamics,  state-of-the- 
art  master  algorithms  in  co-simulation  are  even  today  based  on  constant  communication  step  sizes  and 
do  not  provide  any  automatic  error  control.  Constant  communication  step  sizes  may  restrict  strongly 
the  efficiency  of  co-simulation  algorithms  if  the  solution  behavior  changes  considerably  during  time 
integration.  ” 

A  constant  time  step  size  co-simulation  interface  has  for  example  been  implemented  in  Ptolemy  II  as  part 
of  the  Building  Controls  Virtual  Test  Bed  [28].  The  TISC  [11]  co-simulation  environment  uses  a  variable 
synchronization  step  size.  In  TISC,  a  simulation  module  can  propose  the  length  of  the  next  time  step. 

An  API  that  has  been  available  for  some  time  is  Simulink’s  S-Functions.  S-Functions  are  proprietary  and 
not  standardized,  therefore  not  a  true  alternative  to  FMI  which  aims  to  be  an  open  standard.  S-Functions 
are  also  quite  limited.  For  instance,  being  able  to  discard  a  time  step,  which  is  essential  in  a  number  of 
numerical  simulation  methods,  is  not  possible  with  S-Functions  [3] . 

S-Functions  use  a  split-phase  API  with  two  distinct  functions  per  block,  as  in  Moore/Mealy  state  ma¬ 
chines;  an  Output  function  computing  the  output  of  the  block  and  a  separate  Update  function  that  updates 
the  state  of  the  block.  A  split-phase  API  is  also  used  in  Ptolemy  II  [9],  where  Output  and  Update  are 
called  Fire  and  Postfire.  The  FMI  standard,  as  interpreted  in  this  paper,  supports  indirectly  split-phase 
by  using  fmiGetXXX  as  the  output  function  and  fmiDoStep  as  the  state  update  function.  The  split-phase 
API  is  interesting  as  it  allows  to  decouple  the  computation  of  outputs  for  updating  the  states.  This  in  turn 
enables  delaying  to  commit  a  step,  which  can  be  useful  in  handling  models  where  rollback  is  required,  as 
in  several  examples  presented  above.  A  split-phase  API  can  also  be  useful  in  dealing  with  algebraic  loops 
or  other  model  characteristics  that  require  some  type  of  fixpoint  calculation.  For  instance,  split-phase  is 
essential  in  handling  the  semantics  of  synchronous  block  diagrams  in  a  general  way  [8] .  The  split-phase  API 
can  be  generalized  to  include  more  than  one  Output  function,  which  is  useful  in  dealing  with  hierarchical 
models  [14].  Lublinerman  et  al.  [14]  also  deal  with  the  problem  of  modular  code  generation,  related  to  the 
problem  of  automatically  synthesizing  FMUs  from  models.  This  synthesis  problem  is,  however,  beyond  the 
scope  of  this  paper. 

The  abstract  semantics  of  Ptolemy  include,  in  addition  to  the  Fire  and  Postfire  functions,  the  FireAt 
function  which  enables  handling  timed  actors  (both  continuous-time  and  discrete-event).  FireAt  is  different 
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in  nature  than  Fire  and  Postfire,  in  the  sense  that  while  the  latter  two  are  implemented  by  the  slave  and 
called  by  the  master,  FireAt  is  implemented  by  the  master  and  called  by  the  slave.10  Tripakis  et  al.  [27] 
formalize  the  semantics  of  Ptolemy  using  a  deadline  function,  from  which  the  getMaxStepSize  function  has 
been  inspired. 

The  above  can  be  seen  as  attempts  to  come  up  with  the  “right”  API  for  modeling  heterogeneous  systems, 
and  in  particular,  continuous  as  well  as  (timed)  discrete-event  systems.  Very  relevant  to  this  problem  is 
the  work  reported  by  Denckla  and  Mosterman  [7]  and  Mosterman  et  al.  [19],  who  present  stream-  and 
state-based  functional  interfaces  for  a  Simulink-type  of  language.  Also,  Sander  and  Jantsch  [25]  present  the 
ForSyDe  modeling  framework,  which  provides  a  set  of  libraries  for  capturing  heterogeneous  MoCs  based  on 
the  functional  programming  language  Haskell.  Brornan  and  Siek  [5]  address  the  heterogeneous  modeling 
problem  using  an  embedded  domain  specific  language  (EDSL)  approach. 

Other  approaches  to  tool  integration  apart  include  coordination  languages  [21]  and  tool  buses  [6,  10,  20,  24]. 
These  focus  on  managing  workflows,  general-purpose  distributed  computation,  and  data  exchange  between 
concurrent  tasks. 

Bastian  et  al.  [1]  propose  a  MA  implementation  for  FMI  co-simulation  that  is  designed  to  be  platform 
independent.  Their  MA  uses  fixed  communication  step  size  and  it  assumes  that  FMUs  are  not  dependent 
on  the  current  output  of  other  FMUs.  By  contrast,  our  MAs  have  variable  communication  step  size  and 
supports  direct  dependencies. 


7  Conclusions 

FMI  shows  enormous  promise  for  enabling  interoperability  of  simulation  tools  for  CPS.  We  have  identified 
some  subtleties  presented  by  the  design  of  the  API  in  the  standard,  and  have  offered  constraints  on  the 
design  of  FMUs  and  MAs  such  that  determinate  execution  of  many  models  is  ensured.  We  have  defined  a 
class  of  MAs  that  correctly  handles  models  containing  a  mix  of  FMUs  that  support  rollback,  FMUs  that 
do  not  support  rollback  but  implement  a  proposed  small  extension  to  FMI  for  predictable  step  sizes,  and 
at  most  one  FMU  that  supports  neither.  Even  in  the  case  where  rollback  is  needed,  only  1-step  rollback  is 
enough  for  determinacy,  as  our  master  algorithms  show.  This  is  essential  for  efficient  implementation,  as 
multi-step  rollback  is  very  expensive. 

As  of  this  writing,  the  FMI  2.0  standard  is  still  in  flux.  We  base  our  analysis  on  the  Beta  4.0  version, 
but  the  final  version  may  introduce  additional  subtleties  and/or  problems. 

An  interesting  direction  of  future  work  is  the  composition  of  both  co-simulation  and  model  exchange 
FMUs.  Such  heterogeneous  composition  is  both  practically  important  and  requires  new  kinds  of  MAs. 
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